test: isolate the suite from real user state, and wire integration tests into CI - #63

…rectory

…d error text

…th legs

IDSEC_KEYRING_FOLDER and IDSEC_FILE_LOG_PATH are absolute-path overrides that
bypass the HOME fallback, so a pre-existing value in the developer's or CI
environment sends SDK keyring and log writes outside the sandbox while
AssertSandboxed still reports zero failures. Redirect both, force the SDK file
keyring with IDSEC_BASIC_KEYRING=1 (the OS keyring is a daemon, not a path, and
cannot be redirected at all), and extend AssertSandboxed to cover them.

The redirect list is now asserted against an explicit literal and every entry
gets a hostile pre-existing value before Run: ranging over redirectedVars itself
meant a drop-one mutation survived on four of the original five entries.

Run also restores the environment and removes the sandbox from a defer so a
panic cannot leak either, and saves/restores sandboxRoot so a nested Run hands
the outer root back.

internal/sca, internal/workflows and internal/sdkclient drive the real service
constructors in their retry-policy tests but had no TestMain, so a new test
there could reach real user state with no failing signal. They can hold an
in-package TestMain because testenv imports internal/sca/models, not
internal/sca.

…putFormat

The integration version check accepted `contains("dev") || contains("unknown")`,
and a non-ldflags build always prints "commit: unknown", so the second arm made
it true for any version string. Assert "grant version dev" instead.

The cmd test helpers restored only outputFormat, but newRootCommand binds
verbose to a package global through the same mechanism. Restore both.

isolatedEnv also passes the SDK keyring/log overrides down to the child
process, which inherits the parent environment.

REQ-23 and OUT-26 are the ledger's own PR1 rows; leaving them todo broke the
rule the ledger introduced. Both are flipped to done with the mutation evidence
that closes them.

CLAUDE.md's Test Isolation section now states what testenv covers, what it
cannot cover (the OS keyring is a daemon, not a path), and why XDG_CONFIG_HOME
is defensive rather than load-bearing.

…ior vars

Three of AssertSandboxed's six resolver checks — config.ConfigDir,
config.ConfigPath and cache.CacheDir — could each be deleted outright with
the whole suite still green. The existing failure tests only asserted
len(errs) > 0, which any other assertion in the function satisfies.

Add two cases that pin the failure COUNT and which resolver reported it:
GRANT_CONFIG outside the sandbox isolates ConfigPath (exactly 1), and
HOME+USERPROFILE outside isolates ConfigDir and CacheDir (exactly 2, since
CacheDir delegates to ConfigDir -> os.UserHomeDir). Setting both home vars
keeps the case real on the Windows leg instead of skipping it. recordingTB
now stores the formatted message, because the resolver name is an argument
rather than part of the format string.

Also unset IDSEC_PROFILE and DEPLOY_ENV for the duration of Run. Both are
read by non-test SDK code — the profile loader picks the default profile
name from the first, isp.FromISPAuth resolves the tenant environment from
the second — and neither has a sane sandbox value, so absent is the only
safe state. Restoration preserves the set-vs-unset distinction exactly.

Finally, pass GOENV through to the sandboxed integration build: the child
`go build` resolves its env file via os.UserConfigDir, which the redirect
points at an empty sandbox on Linux while Windows reads an unredirected
%AppData%, so the legs disagreed and any `go env -w` setting was dropped.

…s lines

This branch inserts 13 lines at cmd/favorites.go:148, so every ledger row
below that point named the wrong statement while the header still claimed
the numbers were verified. All nine cmd/favorites.go rows shifted by +13
(OUT-02/03/16/17/18/19/20/24/27), each confirmed against the actual line
content rather than blanket-added. The header now says the numbers are
relative to this branch.

The 23 untagged cmd/*_test.go files compile into the integration binary
too, so their order dependence was never shuffled there — -shuffle=on was
applied only to the untagged build. Add it to the integration step, still
unguarded so both legs run it.

`grant favorites add` also requires a NAME argument, which the new
non-interactive error omitted; it now says so.